A. Technical Field
In general, the present invention relates to authoring of text and computer-executable code, and more particularly to techniques for automatically generating HTML (hypertext markup language) script.
In recent years, the Internet has experienced tremendous growth. Its rapid development has resulted in a growing number of new uses of the Internet and its multimedia component, the World Wide Web (the Web). In particular, demand for richer, faster and more interactive web sites have been driven increasingly sophisticated users. To attract more demanding users, commercial and corporate Internet site authors attempt to stay ahead of their competition by providing more sites for users and potential customers.
Enabling the growth of the Internet, corporate users have expanded the application of HTML into intranets. In this area, creators of authoring tools have strived to enable authors to create content-rich web sites with minimal effort.
When the world-wide web was first invented, the language used to publish data was a simple text-oriented formatting device. A server would send HTML documents to a client computer running a browser that would display the HTML content on the screen according to the formatting information embedded in it. The browser would transmit a request for a particular HTML file and this HTML the server in response to the request would transmit file to the client. These HTML documents contained references to graphic files, which were also sent from the server to the client and displayed according to the embedded instructions in the HTML code.
As the web grew in popularity, second-generation web-sites added more sophisticated formatting such as tables and frames and displayed graphics as background along with other formatting devices. Still, content was still contained in files that were simply transmitted to browsers in response to requests for particular documents. In addition, server-side programs would custom-generate HTML documents in response to requests for specific information. For example the server would access a database in response to a search query and produce an ephemeral HTML document that it would then send to the browser. However, such interactive sites were not common because of the sophisticated server-side scripting that was required. Even after third generations sites, which provided Java script applets, Adobe PDF files, animated graphic files, offered rather sophisticated look to sites, most sites relied on simply pushing fixed documents and applets to browsers in response to specific requests.
Recently with the introduction of Microsoft® Corporation's (of Redmond, Wash.) Visual InterDev® 1.0 product, the process of creating sites that custom-generate files for consumption and display by browsers has been dramatically simplified by employing various interesting techniques. These include:                1. Server-side scripting (Active Server Pages—ASP—developed by Microsoft®) that allows dynamic web applications similar to Java, DHTML, and Active-X, which run on the client. An event occurring on the client is transmitted to the server application and new page-layout data is sent to the client to show the result.        2. ASP objects that are wizard-like components that work similarly to Active-X controls implemented on clients. They have properties, methods, and events and must be instantiated (except for some pre-instantiated components that are always available).        3. Web Bots included in Front Page 97® are server-side components that add functionality like that provided by CGI scripting.        4. Visual InterDev® 1.0's raison d'etre, perhaps, is the convenient integration of databases with web sites without sophisticated programming. This integration is simplified through the use of a compatibility standard and a suite of pre-defined tools that may be incorporated in ASP script.        
ASPs may be called using a URL (uniform resource locator) which may refer to the ASP file “page.asp” as follows: “<http://www.anycompany.com/page.asp>.” While the following description uses the term “active server page” or “ASP,” any document or page which contains a script which, when executed, pulls data from a database and forwards it to an end application (another document or page) falls within the scope of the term, ASP, as used herein.
Requests to ASPs commonly take the form of user requests from a client's browser. An example of a request is a request for current sport scores from a web site. In the process of requesting, the browser, located on the client, accesses the ASP with a request that provides additional information to the server. For example, an active server page, named “scores”, may be connected to a database storing all current sport scores. To access any particular set of scores, a browser user specifies to the server which scores are of interest (here, baseball scores). Next, the browser attempts to access the <scores.asp> file with a “baseball” parameter attached to the file request (e.g., <scores.asp?sport=baseball>. In this example, “scores.asp” is the active server page on the server, “sport” is a filter control handling the parameter “baseball”. In response to this request, the server forwards the desired baseball scores in HTML format back to the browser. Upon receiving this new information, the current page is flushed and the new HTML data (containing the baseball scores in a predefined format) is displayed in the end user's browser. The returned information can also be images, documents, links to images or documents, or other data.
There are a few downsides to the use ASPs in complex sites. First, referring to an ASP with the current scripting parameters is laborious especially with long parameter strings. Developers who are familiar with higher order languages (including C++ and VISUAL BASIC 5.0®) must revert to complex naming schemes for creating the client and server side scripts. This reversion creates the opportunity for errors and the need for additional debugging time.
Also, as currently used, each ASP is directed to a single script. For a large web site, with each and every ASP, no matter how closely they are related, the ASPs require a separate files. Thus, the number of required files for a complex site grows significantly. To this end, maintenance of the site becomes extremely complex and inefficient as each modification to the site may require significant redrafting code for the multiple ASPs. The near duplication of the ASPs can require significant expenditures in time and planning of the web site, when a number of ASPs are so closely related. Currently, there is no efficient way of consolidating ASPs into related groups.
In addition to the above functional elements, Visual InterDev® 1.0 includes a host of features that relate to the development environment. Basically these features include such well-known user-interface features such as drag-and-drop, WYSIWYG, etc. Developers are allowed to instantiate programming objects using a visual metaphor. These ideas are well developed in the Microsoft Visual Basic® product which takes these ideas substantially further than was possible in Visual InterDev® 1.0 for a number of reasons which are explained below.
The development of web applications is complicated by a number of features stemming from the web context. In a classical client-server context, the capabilities of the client computer and those of the server computer are defined in advance of development of applications. In the web environment, the capabilities of the client are not clearly defined. Some clients run browsers such as 2.x browsers lack capabilities, such as the ability to run Java applets that are present in 3.x and 4.x browsers. A web application that seeks to provide sophisticated functionality is confronted with the problem of where to run the code that generates the sophisticated functionality sought: on the client or on the server. Some simple tasks can be performed on “dumb” clients such as forms. A programmer is basically stuck with the problem of writing programs that can handle both situations: putting the sophistication on the server, sending plain HTML to the dumb clients as well as putting the sophistication on the client sending program components to a smart client and letting the client run them.
Another feature of web applications is that the client-server interaction is both ephemeral and contentious in that the number of different clients potentially compete for the limited resources. For this reason, web pages that are generated by server scripts are generally dumped after they are sent to the client. The request data transmitted by the client can be saved for a limited “lifetime” to allow a user to recall the web page. (“Lifetime” may embrace any criterion used for determining whether to persist a page, for example, for a period of time after the user's last visit or as long as the user continues to view and revisit the page without visiting another site, etc.) This involves regeneration of the page. This situation is not too bad in and of itself. However, scripting the calling and called pages to handle the control flow required inevitably involves a lot of tedious old-fashioned sequential coding. That is, at a minimum, to add a page's content, or to employ any script incorporated in the page, to a calling page, the calling page must be scripted to handle the called page, and the called page, a return to the calling page. Conditional branching would also be involved which can be tedious and complex.
There is currently no way to incorporate the functionality of a destination ASP into a current page. Placing the following tag on a client's page “<A HREF=“http://www.anycompany.con/alpha/page.asp”>” allows the user to select the tag and navigate to the ASP named “page.asp” in the “alpha” directory of the www.anycompany.com site. However, once the page.asp is selected with specific parameters, the current page is lost with all its information. The only way to return to the current page and modify the information transmitted to the ASP is by backtracking and re-entering the previously entered parameters. While object-oriented programming exists with respect to other programming areas, there is little or no support for objects in program files of HTML pages including ASPs.
Returning to the general problem of “managing state,” consider the “lifetime” of a simple ASP page that contains a form for data-entry into a database:                User navigates to the page—an HTTP GET causes the server to run the ASP to produce a page for the client.        The browser displays the page and the user enters data and submits the form, causing an HTTP POST to the server.        The server runs the ASP page again to process the post. The code parses the post parameters, updates the database and produces a new version of the page for the client that informs the user the data has been successfully entered.        
It is clear that if the web developer wants to maintain some state information over the lifetime of the page, then simply declaring a variable in client or server code is not sufficient. And obviously the developer must do much more if it is necessary to share this state information between code on the client and server.
There are three categories of state information:                Page—maintained for the lifetime of a page        Session—maintained for the duration of a user's session        Application—maintained for the duration of the application for all users        
ASP supports caching data and objects in the server in the Session and Application objects, providing a means for maintaining session and application state information. A common technique for managing page state is to place values in hidden form elements. The form elements travel with the page to the client, can be modified, and they travel with the HTTP POST data back to the server. A developer using this technique must write server code to create the form elements on the page, write client code to access the form elements through the Document Object Model, write more server code to parse the values from the post parameters, and must be sure to write the values back out in the form elements for the new page that is sent to the client in response to the post. This is another common task that complicates web programming and results in duplication of effort. In addition to the coding overhead, the sheer complexity of sites with a high degree of sophisticated functionality can be oppressive. Being stuck with old-fashioned sequential programs makes the management of the development and improvement of web sites exceedingly complex, even unwieldy.
Finally, the way a client or server accesses an ASP is through script on the client/server page. Managing these scripts can be confusing as the scripts on the server and the client may look similar, yet require slightly different structures and parameter fields. Adding to the level of complexity, in some instances, the server script may generate the client script. To keep track of the complexity of scripts, some page editors color code client script differently from server script. However, as pages become increasingly complex, color-coding is not sufficient to support complex site management as the site becomes increasingly harder to conceptualize.